A central requirement for implementing trusted computing platforms is to validate whether a program executing on a potentially untrusted host is really the program the user thinks it is. In an untrusted environment/host, a program may be compromised in many ways: through static or dynamic replacement of part or all of the binaries, or in the process of static or dynamic linking to untrusted library functions, or through attacks that affect calls and returns. With any of these compromises, the program does not correctly perform its intended functions. The detection of such compromises requires the execution of the entire program to be validated at run time, including the validation of called functions in libraries, the kernel and utilities.
Validating program executions at run-time is a difficult process. Despite the use of non-executable pages [Pax 11a] and address layout randomization (ASLR) [Pax 11b], applications remain vulnerable and an attacker can alter the control flow to take control of the victim applications [Krah 11, Par 10, Sul 06, HHF 09, Bra 08] as they execute. Hund et al. show that run-time attacks can bypass existing mechanisms for assuring the integrity of kernel code and install a rootkit successfully on a windows based system [HHF 09]. Even without any code modification attackers might take control of the application by using jump and/or return oriented programming [BJF+ 11, CDD+ 10, BRS+ 08]. Once a kernel flaw is introduced, it is possible to disable the existing security mechanisms, gain the full control of the victim system and inject code to the kernel memory space [Bra 08]. Digital Rights Management (DRM) applications are also subject to run-time attacks. DRM systems often run as a daemon on the host machine and verify the DRM certificates of the media being accessed and deny access to the copyrighted media in case of the violation on the digital rights specified in the certificate. Rather than getting around the verification and protection mechanism, run-time object code modification might be used to disable the calls to the verification system [Sul 06].
One way to validate the execution of a program is to continuously monitor all attempted changes/updates to the various software components in the program and the rest of the system including the operating system and libraries. The only changes that are permitted are the ones that have been certified as legitimate. Unfortunately, this approach results in a fairly closed system and program execution can be slowed down dramatically if changes to software components that are made at run-time need to be certified as the program executes. Existing approaches to validating the execution of a program include the use of hardware support in the form of the Trusted Platform Module (TPM) [TPM 12] for certifying executables prior to their execution as well as many other techniques that use control flow signatures at run time (Section 2.1).